翻訳と辞書
Words near each other
・ SNAP Interactive
・ Snap It Up! Monster Hits 2
・ Snap Judgment
・ Snap Judgment (game show)
・ Snap Judgment (legal comedy show)
・ Snap Judgment (radio show)
・ Snap kick
・ Snap Kick Productions
・ Snap Lake Airport
・ Snap Lake Diamond Mine
・ Snap matchlock
・ Snap music
・ Snap Out of It
・ Snap oversteer
・ Snap pea
SNAP Points
・ Snap Server
・ Snap Shot (film)
・ Snap shot (ice hockey)
・ Snap table
・ Snap the Whip
・ Snap Yo Fingers
・ Snap Yo Fingers (disambiguation)
・ Snap Your Fingers
・ SNAP!
・ Snap!
・ Snap! (album)
・ Snap! (Aussie Bites)
・ Snap! (programming language)
・ Snap, Crackle & Bop


Dictionary Lists
翻訳と辞書 辞書検索 [ 開発暫定版 ]
スポンサード リンク

SNAP Points : ウィキペディア英語版
SNAP Points

SNAP is the acronym for “Software Non-functional Assessment Process,” a measurement of non-functional software size. SNAP point sizing is a complement to a function point sizing, which measures functional software size. SNAP is a product of the International Function Point Users Group (IFPUG), and is sized using the Software Non-functional Assessment Practices Manual, now in version 2.2.
== Introduction ==

The International Function Point Users Group () now recognizes two complementary software sizing metrics. The first metric is “function points”. Function points (FP) are units of measurement to express the amount of business functionality a software application provides to the user. It measures the flow and storage of data through a software application. Specifically how that is done through IFPUG is described in the IFPUG Counting Practices Manual (CPM). The International Organization for Standardization, ISO, describes functional user requirements as “a subset of the User Requirements (UR). Requirements that describe what the software shall do, in terms of tasks and services.” 〔ISO/IEC 14143-1:2007 Information technology – Software measurement – Functional size measurement – Part 1: Definition of concepts, International Organization for Standardization, 2007〕
The IFPUG Software Non-functional Assessment Practices Manual (APM) 〔International Function Point Users Group, Software Non-functional Assessment Practices Manual 2.1, International Function Point Users Group, Princeton Junction, NJ 08551〕 describes how to size the non-functional requirements.
SNAP currently recognizes four general categories, each broken down into subcategories. Each subcategory is measured using the process in the APM.
;1. Data Operations
1.1.Data Entry Validations
1.2.Logical and Mathematical Operations
1.3.Data Formatting
1.4.Internal Data Movements
1.5.Delivering Added Value to Users by Data Configuration
;2. Interface Design
2.1.User Interfaces
2.2.Help Methods
2.3.Multiple Input Methods
2.4.Multiple Output Formats
;3. Technical Environment
3.1.Multiple Platform
3.2.Database Technology
3.3.Batch Processes
;4. Architecture
4.1.Component Based Software
4.2.Multiple Input / Output interfaces
The correlation between non-functional size using SNAP points and the work effort to provide them was proven during the beta test conducted in the fall 2012. The statistical correlation between the SNAP size of 48 randomly, internationally selected applications and the corresponding work effort to develop the SNAP points for those applications was found to be close to 0.89.
The overall size of software consists of separate components, functional and non-functional, for example, “400 function points and 200 SNAP points”. The two sizes do not sum up to one single size. The IFPUG functional sizing methodology does not change when measuring the non-functional requirements using SNAP.
Non-functional sizing requires recognition of similar artifacts of software used to measure functional size, for example: data element types (DETs) and file types referenced (FTRs).
Separating functional and non-functional requirements is important when performing a cost forecast (or other forecast such as scheduling or staffing) for software development. In principle, a cost forecast can now be made for the function point development effort, and a second forecast must be made for the SNAP development effort. The sum of both efforts will support the best estimate of the total effort for the software development.
There are a few other comments to make as cost forecasting models built before SNAP were built on function points alone.
* Some function point-based cost estimation models may already consider factors that are non-functional. For example, some of the traditional General Systems Characteristics (GSC) which may be traditionally included as part of the adjusted function point count as the “Value Adjustment Factor” (VAF) (CPM, v. 4.3.1, Appendix C) are also currently measured with SNAP.
* Some commercial software cost estimators may have productivity settings that account for the impact of non-functionality.
* Some care is needed to avoid the effect of duplication when arriving at cost estimates using both function points and SNAP points. Work effort used to develop function points cannot be also credited with developing SNAP points, as these are two separate aspects of software.
Function points have been in academia and industry since the publication of Allan Albrecht’s paper “Measuring Application Development Productivity.”;〔Albrecht, Allan, “Measuring Application Development Productivity” Proceedings of the IBM Applications Development Symposium, Monterey, CA (USA) Oct 14-17, 1979. (BFPUG: Brazilian Function Point Users Group ) (see ‘Artigos/Temas’)〕 the methodology has matured by years of research and practice into what is now recognized as the IFPUG CPM. SNAP is new. The IFPUG Non-functional Sizing Standards Committee (NFSSC) expects that SNAP, too, will mature over the years as it is being released into academia and industry for research and practice. These are exciting times, as software cost forecasting (and other forecasting) continues to move away from being an art into a science.

抄文引用元・出典: フリー百科事典『 ウィキペディア(Wikipedia)
ウィキペディアで「SNAP Points」の詳細全文を読む



スポンサード リンク
翻訳と辞書 : 翻訳のためのインターネットリソース

Copyright(C) kotoba.ne.jp 1997-2016. All Rights Reserved.